home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 98 / Skunkware 98.iso / src / net / bind-contrib.tar.gz / bind-contrib.tar / contrib / misc / checker / text0000.txt < prev   
Encoding:
Text File  |  1996-10-25  |  4.8 KB  |  94 lines
  1. Paul A Vixie writes
  2. > 
  3. > i am willing to look at checker if someone sends me a copy.
  4.  
  5. Date: Fri, 28 May 93 16:09:43 PDT
  6. From: smiller@caldera.usc.edu (Stephen B. Miller)
  7. To: ellozy@farber.harvard.edu
  8. Subject: The Checker Project
  9.  
  10. Mohamed,
  11.  
  12. Please ftp from ~ftp/pub/checker on caldera.usc.edu for the code and 
  13. documentation on our research work with the DNS query traffic that I 
  14. mentioned yesterday.  Also included there is the announcement that I 
  15. am mailing to the bind mail group about the project.
  16.  
  17. Stephen Miller
  18.  
  19. Its still there, here is the announce.txt:
  20.  
  21. The earlier request for aid from Mohamed Ellozy has prompted me to go
  22. ahead and release some information on a project ongoing at USC that 
  23. might be of some aid to others like him.  With this announcement I
  24. am hoping to get some discussion on the concepts implied below, and
  25. suggestions for things that I should be testing for.  Please feel free
  26. to dredge up any old history as I have only been watching bind activity
  27. for about a year and have only managed microscopic domains by comparison
  28. to some of you.
  29.  
  30.                          The Checker Project
  31.  
  32. The following work is an extension of the paper titled "An Analysis of 
  33. Wide-Area Name Server Traffic" by Danzig, Obraczka, and Kumar from the 
  34. 1992 SIGCOMM.  A postscript copy of the paper is available on anonymous 
  35. ftp from caldera.usc.edu in the ~ftp/pub/checker directory.  Design,
  36. coding, and testing has been conducted by Stephen Miller (smiller@
  37. caldera.usc.edu), Peter Danzig (danzig@usc.edu), and Anant Kumar
  38. (anant@isi.edu) in the USC networking research laboratory.
  39.  
  40. The Checker Project is an attempt to build onto named the ability to 
  41. scan the incoming query traffic looking for client machines that may be 
  42. experiencing problems getting their requests satisfied.  The project
  43. itself is a set of C code that builds a database from the nameserver 
  44. query and response traffic.  Whenever a query or response is passed 
  45. through the checker code its timing and response code is checked against 
  46. some historical parameters to see if the client's activity falls within 
  47. some behavioral patterns previously identified with some broken resolver 
  48. or nameserver implementations.  Reports are generated upon request and 
  49. include such things as: activity summary, client address sorted by 
  50. number of different queries, query name sorted by number of requests, 
  51. and client addresses that have had behaviors that fall with the 
  52. predefined patterns.
  53.  
  54. Knowing that Paul Vixie was putting immense effort into the 4.9 version 
  55. I chose to make as few incursions into named as possible, which resulted 
  56. in 5 lines of code being changed in each of ns_req.c and ns_resp.c (not 
  57. including some ifdef/endif sets).  As far as I can tell the changes that 
  58. we made to let us test with bind 4.8.3 are still valid in 4.9.  Even
  59. though the code is present in the ftp directory mentioned above I would
  60. respectfully request people to email me before taking a copy as there
  61. are changes being made.  Please feel free to get a copy of the postscript
  62. installation and operations guide.  Any comments on that are especially
  63. welcome.  The C dialect is pretty generic, but testing has only been done
  64. using SunOS; following Paul's style for handling multiple platforms is
  65. on my list of things to do.
  66.  
  67. The current alpha version of Checker has been running one of the roots
  68. for the US domain for a few weeks with no failures, under a load of
  69. several thousand queries a day.  Our initial experiences show some good
  70. stuff, along with some things to look at.  We have had no problem seeing
  71. the clients that seem to be making a lot of absurd queries, but I doubled
  72. named's dynamic memory usage at the same time.  Memory usage is configured
  73. by the record cache time though, and I tend to run long periods on our
  74. research machine. Other upgrades coming include altering the reports to
  75. show query rates rather than absolute counts.  After running for a week
  76. without rebooting the counts get very large, but divided by the time
  77. factor show no real problem.
  78.  
  79. An interesting feature, currently disabled for the US domain testing, is
  80. the ability for the program to randomly choose a query name, and eat all
  81. replies to that name for a short (configurable) period of time.  The
  82. theory behind this is that the client should choose another server pretty
  83. quickly and stop using the one that isn't replying.  If the client keeps
  84. asking then the DNS implementation the client is running may need to be
  85. upgraded.  During the first phase of testing when I directed USC's 
  86. networking laboratory toward a named-checker installation we found that
  87. most of our installations behaved as predicted.  I have not turned this
  88. feature on yet for the US domain as we still have yet to fully understand 
  89. the passive mode for the larger amount of traffic.
  90.  
  91. Stephen Miller
  92. University of Southern California
  93. smiller@caldera.usc.edu.
  94.